In networked database technologies, hierarchical databases such as online analytical processing (OLAP) databases, extensible markup language (XML)-based data stores, and others are known. During operations with hierarchical data stores, it is sometimes necessary or desirable to add or insert additional data values into nodes which lie beneath the parent node in the hierarchy. For instance, if a parent node stores financial data reflecting annual profit for a corporation or other entity, it may be desired at the same time or a later time to insert lower-level breakdowns of that data over smaller intervals. For example, it may be desired to insert child nodes which store quarterly or monthly profit for that entity. In general, the process of pushing or distributing data down to child nodes or other destinations in the database structure can be referred to as “spreading” the data.
In known database platforms, the ability to perform spreading operations can be constrained or limited by limitations in the data structures and logical operations permitted on those platforms. For one, while platforms may exist which permit a user to insert a new child node at a lower level in relation to a parent node, data may only be distributed down from one parent at a time. If, for instance, annual profit is intended to be expanded or spread down to quarterly profit entries over the last ten years or some other group of years, the user may be forced to manually insert the child nodes and manually perform the spreading, year by year.
For another, when performing distribution of data between nodes or levels in a hierarchical data store, the order in which spreading is performed can have effects which the database engine does not take into account. For instance, when spreading annual profit down to quarterly nodes, it may be necessary to check for special charge offs or other factors against profit in a given quarter, or profit for a first fiscal quarter may be affected by a carry-over entry from the previous fiscal year end. Other factors or dependencies can apply, but existing database platforms do not permit the incorporation of dependency rules or other logic to ensure data accuracy or integrity.
Other shortcomings in existing database engines exist. For instance, in a rules-based platform it may be desirable to detect, trap, and attempt to cure a numerical fault, logical fault, and/or other source of erroneous or irregular data spreading outputs. For example, if it is discovered that the insertion of a particular spreading rule causes division by zero in a computation, cell, or other output, tracing and identification of the offending rule to permit suspension, adjustment, or removal of that rule may be helpful. It may be desirable to provide systems and methods for generating a push-up alert of fault conditions in the distribution of data in a hierarchical database which permit the isolation of conflicting rules, notification to the user of that condition, and potential corrections to the set of rules or other parameters to restore reliable data spreading operations.